Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="6m83Ju1wTEGIEn2C"


--6m83Ju1wTEGIEn2C
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

'Robin Larrieu' via pqc-forum writes:
> Moreover, in PKCS-#11 incremental verification, the signature is 
> available only during C_VerifyFinal, when the whole message has been 
> processed.

With this type of interface, typical applications end up processing
streams that haven't been verified yet, and the attacker can trivially
feed forged data to the applications.

Since this type of interface is dangerous from a security perspective,
creating hassles for this type of interface should be viewed as a
positive feature of a spec rather than a negative feature.

It would be useful to instead specify secure signing for streams. For
example, the verifier maintains a transcript hash h (starting as context
or simply a constant), receives a signed packet (h,p,s) where h doesn't
need to be transmitted explicitly, opens the signed packet to recover
plaintext p, outputs p, updates h to H(h,p) where H is a hash function,
and moves on to the next packet. It should be feasible with current
techniques to computer-verify the security properties of such designs.

Instead of sending (p,s) in clear, I would send AONT(p,s) with any AONT
in the literature, preferably keyed by h: for example, xor a hash of
(h,s) into p, xor a hash of (h,p) into s, and so on for whatever number
of rounds. 4 rounds are ample, and even 1 round (just xoring a hash of
(h,s) into p), with a very weak hash function, would probably do the job
of encouraging applications to call the proper cryptographic functions
rather than extracting and releasing p. But the hash function H used to
update h has to be strong so that the attacker can't rearrange packets.

An alternative to signing (h,p) is to sign H(h,p), so the receiver takes
(p,s), replaces h with a hash of (h,p), and opens the signed message
(h,s). However, this seems to increase the damage done by collisions.
Most applications shouldn't notice the cost of an extra hash layer.

If all data is available to the signer in advance then of course one
signature on a hash tree suffices, and it's easy to arrange hashes so
that packets can be verified in parallel. This covers the "we need to
quickly verify firmware on boot" use case.

---D. J. Bernstein

-- 
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20220818180023.72479.qmail%40cr.yp.to.

--6m83Ju1wTEGIEn2C
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3QolqQXydru4e4ITsMANTjsOVFkFAmL+fjcACgkQsMANTjsO
VFmyThAAxcXZJ7GwNVu94Ynr43DwYewZWqDklGpbYpIp6l6KDaG4n3eyTpQRxtqW
cw7yYBdg2HCTIur+t5PbgquQZ4m3Oq/F45XTUtQ85MBbuDPoEbqAxlFQaeyzv8Tx
+AAahZkEOc6Ymi3wllaNj1uJ6c8vew1tp+WgHuHKX6gXUJE04ONEafxGaE4J9KeI
33qg1gfHi5vvvqrqGHyyoRUtRdQIhBRfWEsfm1xg/ARIkZpvvIgdk/WU9Ir1pGqW
mY8Wju8yiqgJA72H8VDd+REo058iGkJ0ApACVeDavPGwVDbnr1B4UYUJGqRBl5A2
BlOjDXANv3bcbJYEaiAjWkzUT48qqeo4NJT2d2fZZwrtqIyCnxvk4cxbYGa2yoWo
BfrODePDMXYfWZv83wc/UFcPtkZxkKOgZgFttFO0CnW+H6ap/UJbJbrQZ9qiRr/S
DZtPFh/UdNMVq5baFs2ABoLYgm2q76dph46c7+Vgi5ev2SfyyJf/9KimkITpOfd2
YvBn2Rawl9bw9NOXvhD8mzYT4110p6oWYvwJR6gdMpmOXpghPOa9xIRfyPRwqSuk
QcDzMKL183GL/qmMvo52ZgejY20Hd2BkQ53Lb6i2ugXZWr5+qGEGrNcj4IA2Sm6Y
DOOnHpXMpXD3g+2ZST1qX1iaC42/Wpe24h3B+Hg/9ZRHtdxPg0U=
=GVZx
-----END PGP SIGNATURE-----

--6m83Ju1wTEGIEn2C--